Small Computer System Supports 
Large-Scale Multi-User APL 

Powerful, interactive APL is now available for the multi- 
lingual HP 3000 Series II Computer System. A special 
terminal displays the APL character set. 

by Kenneth A. Van Bree 



APL (A PROGRAMMING LANGUAGE) is an 
interactive language that allows access to the full 
power of a large computer while maintaining a user 
interface as friendly as a desktop calculator. APL 
is based on a notation developed by Dr. Kenneth 
lverson' of IBM Corporation over a decade ago. and 
has been growing in popularity in both the business 
and scientific community. The popularity of APL 
stems from its powerful primitive operations and 
data structures, coupled with its ease of programming 
and debugging. 

Most versions of APL to date have been on large and 
therefore expensive computers. Because of the ex- 
pense involved in owning a computer large enough to 
run APL. most of the use of APL outside of IBM has 
been through commercial timesharing companies. 
The introduction of APL\3000 marks the first time a 
large-machine APL has been available on a small 
computer. APL \3000 is a combination of software for 
the HP 3000 Series II Computer System 2 and a CRT 
terminal, the HP 2641A, that displays the special 
symbols used in APL. The terminal is described in the 
article beginning on page 25. 

Although the HP 3000 is normally considered a 
small computer, APL\3000 is not a small version of 
the APL language (see pagel4). As a matter of fact. 
APL\3000 has many features that have never been 
available before, even on the large computers. For 
example, although APL\3000 looks to the user just 
like an interpreter, it is actually a dynamic compiler. 
Code is compiled for each statement as it is encoun- 
tered; on subsequent executions of the statement, if 
the compiled code is valid, it is re-executed. By 
eliminating the interpretive overhead, a speedup on 
the order of a factor of ten can be obtained in some 
cases, although the speedup is dependent on the 
amount of computation involved in the statement. 

The basic data type of APL is an array, which is an 
ordered collection of numbers or characters. Sub- 
script calculus, as defined by Philip Abrams, 3 is a 
method of selecting portions of an array by man- 
ipulating the descriptors that tell how the array is 
stored. The use of subscript calculus in the dvnamic 



compiler allows computation to be avoided in many 
cases, and eliminates the need for many temporary 
variables to store intermediate results. 

One problem that has always plagued APL users is 
the limited size of most APL workspaces. A work- 
space in APL is a named data area that contains all the 
data variables and functions that relate to a particular 
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APL Scripts 



A Edit interactive program and execute. 

B Edit simple calculation program and execute 

C Assignments and addition in calculator mode 



D Compute bound large workspace swapping program 
E Compute bound simple calculations. 
F Compute bound primes program 



Fig. 1. Average response limes 
for a range of activities on an HP 
3000 Series II System used only 
Icr APL and similar data lor a 
range ol APL activities on a multi- 
lingual HP 3000 Series II System, 
A system with 512K bytes ol main 
memory will support up to 16 APL 
terminals 



problem or application. Most other APL systems limit 
a workspace to 100.000 bytes or less. APL\3000 
eliminates this limitation by giving each user a vir- 
tual tvorkspace. A workspace is limited only by the 
amount of on-line disc storage available. 

APLA3000 is the first APL system to include 
APLGOL 4 as an integral part. APLGOL is a block- 
structured language that uses keywords to control the 
program flow between APL statements. To facilitate the 
editing of APLGOL programs, and to provide an en- 
hanced style of editing for APL programs and user data, 
a new editor was added to the APL system. This editor 
can be used on both programs and character data, and 
includes many features never available before in APL. 

One of the features of APL that makes program de- 
velopment easier is that program debugging can be 
done interactively. When an error is encountered in an 
APL program, an error message is displayed along with 
a pointer to the place where the error was detected. 
Execution is suspended at this point, and control is 
returned to the user. In other versions of APL, the user is 
allowed to reference or change only the variables that 
are accessible within the function in which the error 
occurred, and must resume execution within that func- 
tion. APL\3000 has implemented a set of extended 
control /unctions that allow die user to access or change 



any variable in the workspace and resume execution 
within any function that has not yet completed execu- 
tion. These extended control functions can be used to 
implement advanced programming techniques that 
were previously difficult or impossible to implement in 
APL. An example is backtracking, which involves sav- 
ing the control state at various points in the computa- 
tion and returning to a previously saved control state 
when an error is detected. 

The new features of APL \3000 are described in detail 
in the articles that follow. 

Performance Data 

An HP 3000 Series II System with 512K bytes of main 
memory will support a maximum of 16 terminals using 
APL, or a combination of terminals using APL and other 
languages. Fig. 1 shows typical response times for vari- 
ous combinations of terminal types, APL program 
loads, and memory sizes. 
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Introduction to APL 



APL (an abbreviation tor A Programming Language) is a 
concise high-level language noted for its rich variety of built-in 
(primitive) functions and operators, each represented by a 
symbol, and its exceptional facility for manipulating arrays 

APL uses powerful symbols in shorthand fashion to define 
complete functions in very few statements or characters For 
example, the sums of each of the rows (n a very large table 
called T are + -T. The sums of the columns are + /[1 ]T. The 
grand total of all numbers in the table Is simply + / ,T Sorting 
and adding tables and other common operations are just as 
simple. 

These characteristics, combined with minimal data declara- 
tion or other language requirements, help substantially reduce 
programming effort. Typical interactive APL programs take only 
10-30% as long to write as would equivalent programs m other 
languages, such as FORTRAN or BASIC 

APL was invented by Dr. Kenneth E. Iverson at Harvard Uni- 
versity. In 1962 a description of his mathematical notation was 
published. By 1966, IBM had refined the notation into a lan- 
guage and implemented the first version of APL on an experi- 
mental timesharing system By 1969 APL was an IBM program 
product and several independent timesharing services began 
providing it. 

Because APL is both easy to use and tremendously powerful 
it has gained widespread acceptance A large, swiftly growing 
APL timesharing industry has developed Approximately 70% of 
IBM's internal timesharing is done m APL Over 50 North Ameri- 
can universities including Yale. MIT, UCLA, Syracuse, Univer- 
sity of Massachusetts (Amherst), York, and Wharton have in- 
house systems. Popularity has grown in Europe, especially 
Scandanavia and France. 



Although initially designed for scientific environments, APL's 
features proved to be ideal for processing business data in 
tabular formats Now. most timesharing services find approxi- 
mately 80% of their APL business is in the commercial applica- 
tions area. 



APL Characteristics 

A symbolic language with a large number ot powerful primitive func- 
tions. 

Uses righl lo left hierarchy (as opposed to precedence) thai can be 
overridden by parentheses. 

Designed to deal with arrays of numbers as easily as other languages 
deal with individual items 

Minimum language constraints: very few syntax rules: uniform rules 
for all data types and representations: automate management of 
data storage and representation 

APL Advantages 

Programs can be developed in 10-30% of the time and code space 
required by languages like FORTRAN. ALGOL and BASIC 
Concepts of a program can oflen be more quickly grasped because 
ot the brevity and conciseness ol APL code 

Very flexible programs easy to change data very accessible and 
easy to rearrange 

Fig. 1. Characteristics and advantages ol APL 
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BASIC 

10DIM A(100) 
20 READ N 
30S=0 

40 FOR 1=1 TO N 
50 READ A(l) 
60S=S-rA(l) 
70 NEXT I 
30 PRINT S 
90 END 



FORTRAN 

DIMENSION A (100) 

READ |5 10) N 
10 FORMAT (13) 

READ 15.20) (All). 1*1, N) 
20 FORMAT .8E10 3J 

S=0.0 

DO 30 1=1. N 
30S=S+A(I) 

WRITE (6.40)S 
■SO FORMAT (E12 3) 

END 



ALGOL 

REAL S 
INTEGER I N. 
GET N, 
BEGIN 

REAL ARRAY A (1 N). 

s=oo 

FOR I -l TO N DO 
BEGIN 
GET A(l) 
S-.=S+A(l). 
END. 
PUT S 
END 



APL 

'.a-c 



Fig. 2. Comparison ol steps required to 'ead and sum a list ol numbers- 



R = Revenues by product and salesman 
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Find each salesman's total commission where the lormula lor 
Fintl . / commission is 6.2% of profit, no commission tor any product 

to total less than zero 



Answer: 



Commission 



Johnver 
92 



Vanston 
5 



Danbree 
113 



Vansey 
45 



Mundyke 
32 



Explanation of APL Code Required: 

062 » * t Ol R-E 



.AAA 



■ Step 1 Subtract each item in matrix E from each item in matrix R 

Step 2. Find maximum ol each item in resultant matrix versus the value of zero 

Step 3 Sum over new resultant matrix by rows 

■ Step 4 Multiply individual items in resultant vector by 062 
Step 5 Automatically print new resultant vector 



Comparison of APL Code Required With BASIC Code Required: 
APL 



062 x +/ 0 R-E 



BASIC 



10 FILES DATA 

20 DIMENSION R(4,5), E(4,5). T(5) 
30 MAT READ # 1 . R,E 
40 MAT T = ZER 
50 FOR P = 1 TO 4 
60 FOR S = 1 TO 5 

70 T(S) = T(S) * 062-(R(P.S)-E(P.S))MAX0 

80 NEXT S 

90 NEXT P 
100 MAT PRINT T 
110 END 



Fig. 3. Explanation ol APL code using typical example 
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APL Data: Virtual Workspaces and 
Shared Storage 

by Grant J. Munsey 



MUCH OF THE POPULARITY of APL can be 
attributed to the convenient way it handles 
data. Most other programming languages treat vari- 
ables as volatile "scratchpad" areas that are occupied 
by meaningful data only while programs are execut- 
ing. Before programs can run, they must load the 
variables with data, usually by reading a file. During 
program execution the data is accessed by referring 
to variable names. When execution is completed, 
the meanings of the variables are lost unless the pro- 
grams explicitly save their data in another file. APL, 
on the other hand, provides direct access to named 
data items, large or small, without forcing the con- 
cept of a file on the programmer. Once values are 
assigned to APL variables, they are accessible by 
name either in program execution mode or in calcula- 
tor mode. The relationship between the data and the 
name is preserved until the programmer chooses to 
purge the data. The variables and the functions that 
operate upon them are preserved together, which 
means that APL applications need not go to files to 
access and save data. 

In APL a unique name is attached to each distinct 
set of data by means of the assignment arrow: 
DATE*- 7 4 1776 

OCCASION"- 'independence day' 

APL \ 3 000 variables may be either scalar (single- 
element) or array-shaped with up to 63 dimensions. 
Though conceptually there are only two data types in 
APL, character and numeric. APL\3000 actually 
stores its data in a variety of ways for efficiency. APL 
differs from most other programming languages in 
that an APL programmer is never involved in specify- 
ing or choosing these machine-dependent internal 
representations; the APL system automatically 
chooses both the most efficient and the most accurate 
representation for any given set of data. 

Likewise, an APL programmer never writes decla- 
rations specifying the shape, size, or amount of stor- 
age that will be required for a variable. Variables are 
declared by assigning data to them, and the APL sys- 
tem allocates the appropriate storage in which to re- 
tain the data. Readers familiar with languages requir- 
ing declaration of variables (e.g.. FORTRAN, BASIC. 
COBOL) will recognize that the task of setting up such 
declarations can often take a substantial amount of 
programming time. 

An interesting and useful feature of APL is that a 



particular variable name may, at different points in 
time, refer to different types and shapes of data, as the 
following sequence illustrates: 

A-3.5 
A-z 4 6 8 

A -'WHAT WOULD WE APPRECIATE?' 

A— 2 3 pi 2 3 4 5 6 

A 

1 2 3 
4 5 6 

In this example, A is first assigned the numeric scalar 
3.5. Then A is assigned the numeric vector 2 4 6 8. 
Next, A is assigned the character vector 'what would 
WE appreciate?'. Finally, A is assigned a two-row, 
three-column array of numbers, then printed. Notice 
that each statement whose result is not explicitly as- 
signed causes the result to be automatically printed. 

The Workspace Concept 

As functions and data are created, they remain as- 
sociated with their user-assigned names in an area 
called the active workspace. This area can be named 
and saved for later use by entering the system com- 
mand: 

)SAVE WSID 

where ws/d is a user-specified workspace name. This 
saves a "snapshot" of all currently defined functions 
and data items. A saved workspace may be later re- 
activated by entering the system command: 
JLOAD WSID 

The concept of workspaces provides a convenient 
means for working on several different problems, 
each of which has its own set of pertinent data. For 
example, an accountant might have several custom- 
ers for whom he is keeping payrolls. Several work- 
spaces might be maintained, each containing payroll 
information for a particular client. Whenever a salary 
report is needed for a client, the appropriate work- 
space could simply be loaded and the report gener- 
ated. Notice that workspaces are much like folders in 
a filing system; each holds the information required 
for a specific job. 

Since all functions and data for a problem are stored 
in a single workspace, workspaces tend to grow very 
large as problem size increases. Yet most existing 
APL implementations have limited the size of work- 
spaces, typically to less than 100.000 bytes. This con- 
straint either imposes an artificial limit on the size of 
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applications attempted, or forces the more deter- 
mined programmer to seek additional storage outside 
of the workspace by explicit use of a file system, a 
definite violation of the general spirit of APL pro- 
gramming. 

The HP 3000 is a small computer with a limited 
amount of main storage. Yet APL .3000 has avoided 
the traditional workspace size restrictions by employ- 
ing two strategies: shared data storage and virtual 
workspaces, 

Shared Data Storage 

Shared data storage helps solve the workspace size 
problem by conserving storage. Multiple copies of the 
same data are avoided in many cases by allowing 
arbitrary numbers of variables to share the same data 
area. Consider the following two statements: 
A«- 1 2 5 6 9 10 
B-A 

The first statement creates a data area for A. while the 
second specifies that B is to be assigned whatever is in 
A. While one could naively make a second copy of the 
data and attach it to B, this is completely unnecessary 
and is a waste of storage: B should be able to share the 
original data with A. 

A potential problem is: if A and B share the same 
data area, what happens if either of the variables 
changes part of its values? Does this affect the other 
variable? For instance, the subscripted assignment 
B[3]-20 

should not have the effect of also making a[:j]'s value 

20. 

Copy-on-Write 

APLN3000 solves this problem by attaching a re- 
ference count to every data area, and keeping track of 
how many variables are referring to it. Partial changes 
to a data area (e.g.. B[3]--20) are allowed only if its 
reference count is 1 (i.e., it is unshared). A data area 
whose reference count is greater than 1 is never 
changed, since more than one variable is referring to 
it. Instead, a "copy-on-write" policy is adopted: the 
variable to be written into is given its own private 
copy of the data, the reference count of the original 
shared data area is decreased by 1, and the original 
data remains unchanged. 

Shared data storage is useful in that it frequently 
allows the APL system to avoid making multiple 
copies of identical data. But this is really only a wel- 
comed side effect of the real purpose of shared stor- 
age: allowing the dynamic compiler to implement 
certain selection functions and operators by applying 
Abrams' subscript caicuJus. 2 This technique is used 
to improve the performance of APL 3000, providing 
a two-fold justification of shared storage: space and 
speed. 



Subscript calculus places another requirement on 
the APL system besides shared data areas: a variable's 
data area must be decoupled from its accessing in- 
formation. That is. the data area itself must not de- 
scribe the method of storing the data therein. To un- 
derstand why this is required to perform subscript 
calculus, the attributes of APL data must be recalled: 
it has some actual collection of values, and it has a 
particular size and shape. Consider a numeric vari- 
able ABC whose data is arranged in two rows and three 
columns: 
ABC 

1 2 4 
0 5 9 

The storage for ABC contains six data elements that the 
user thinks of as a two-dimensional array. At the 
machine level, however, storage is actually accessed 
in a linear fashion, as if it were a vector. To access any 
given element of ABC. the APL system takes a set of 
user indexes, consisting of a number for each dimen- 
sion in ABC. and calculates a linear address into the 
data area holding ABC's values. 

It has been common practice to store data in what is 
called row major order. In this scheme, data is stored 
with the rightmost subscript varying the fastest. For 
example, the actual linear layout of the variable ABC 
stored in this order would be: 

1 2 4 0 5 9 

ABC[0:()J ABC[0:l] ABC[0;2] ABC[l;(l] ABC.[l;l] ABC[l:2] 
Notice that zero-origin indexing was used (the first 
element in any dimension is index 0). Zero origin will 
be used in all formulas and examples hereafter. 

When data is stored in row major order, one can 
map a set of user indexes into a machine address by 
employing the formula: 1 

RANK -I RANK I 

ADDRESS- % * II SHAPE [k] HI 

I'D K = l»l 

where I is the set of user indexes. In addition to the 
user indexes, this formula requires some information 
about the data's exact size and shape: RANK is the 
number of dimensions in the array, and SHAPE is a 
vector of the sizes of each of the dimensions. Together 
RANK and SHAPE make up the variable's row major 
access information. 

Applying equation 1 to calculate the actual address 
of the element ABC [0:2]: 

I : 0 2 

RANK : 2 
SHAPE : 2 3 

ADDRESS = (1[0] x SHAPE [l]) + (l(l] X 1) 
= (0 x 3) + (2 x 1) 
= 2 

Referring back to the description of how ABC is 
stored, it can be seen that ABC [o;2] is indeed at loca- 
tion 2. Thus for data stored in row major order, all that 
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is needed to calculate the actual storage address of an 
array element from a set of user indexes is the RANK 
and SHAPE of the data. 

In AFL systems not concerned with performing 
subscript calculus, this accessing information is tra- 
ditionally stored with the data itself, which makes 
every data area self-describing. Subscript calculus, on 
the other hand, wants to view data in many different 
ways without physically rearranging it. The opera- 
tion of subscripting (e.g.. ABC [ and the functions 
TAKE, DROP, REVERSAL, TRANSPOSE, and RESHAPE can be 
implemented so that they rearrange data without ac- 
tually moving or copying it, but only if the data area's 
accessing information is not an integral part of the 
data. Consider, for example, the APL function that 
reverses the columns of an array. 

ABC 

1 2 4 
0 5 9 

RABC— | ABC 
RABC 

4 2 1 
9 5 0 

If the result of the reversal must always be stored in 
row major order, then nothing can be done except to 
make a second copy of ABC's data for RABC. with its 
order rearranged. But if one can depart from row 
major storage order in this case, one can generate new 
access information for RABC, and it can share ABC's 
data area with no data movement required. This re- 
quires generalizing the storage mapping function de- 
veloped above to allow other storage arrangements 
than row major. The new formula will be: 
hank - 1 

ADDRESS = OFFSET + V I [j] x DEL [j] (21 

I i u 

This generalized formula makes explicit something 
that equation 1 was able to imply by knowing that 
data was stored in row major order: OFFSET is always 
zero: and del [[] is always 

RANK-l 

[I SHAPE [K], 

K |-l 

The new formula requires that both of these be 
made part of a variable's data accessing information. 
Equation 2 can be checked by again calculating the 
address of element AUC [0:2]: 



I 


0 2 


RANK 


2 


SHAPE 


2 :i 


DEL 


3 1 


OFFSET 


0 



ADDRESS = OFFSET + |l[o] x DEL |o)j - X DEL [l]| 

= 0 + (0 x a] + [2 x 1) 
— 2 

This is the same address calculated by applying equa- 



tion 1, so equation 2 seems to work, at least on row 
major data. This new formula can be used to share 
ABC's data with RABC: 

1 2 4 u 5 9 

Anc[t):0] AHC[();l] AHC[0;2j ABC|l:0j ABC[l;l] ABC[l:2] 
RABC [0;2] RABC [0;l] RABC [l);0] RABC [1.2] RABC [til] RABC 

By changing both the DEL vector and the OFFSET as 
shown below, kabc can be totally described by its 
accessing information. As a check, equation 2 can be 
used to calculate the storage address of element kabc 
[0:2]: 

l : 0 2 

RANK : 2 

SHAPE : 2 3 

DEL : 3 -1 

OFFSET : 2 

ADDRESS = OFFSET + (l[oJ x DEL [0]) + (if 1 ] * DEL [\]) 
= 2 * (0 x 3) t (2 x (-1]) 
= 0 

Referring back to the data area shared by ABC and 
RABC. it can be seen that kabc f o;2 1 is indeed at address 
0 of the shared data area. 

Thus by including the DEL vector and the OFFSET in 
a variable's set of accessing information, data areas 
can be shared among variables whose conceptual or- 
derings differ. Notice, though, that each variable must 
have its own private set of accessing information for 
this to work, otherwise the shared data area can only 
be interpreted as one shape and storage method. 
Using a set of transformations to the DEL vector and 
the offset in the above manner to rearrange data 
without actually moving it is the essence of subscript 
calculus. 

Virtual Workspaces 

The WS FULL message is well-known to most APL 
programmers. In specific terms, it means that the ac- 
tive workspace has filled up and program execution 
has stopped. In more general terms, it usually means 
that the programmer is going to have to do a lot of 
work to circumvent the problems of limited work- 
space size. 

APLA3000 uses a technique called virtual storage 
to remove the workspace size limit. This allows the 
user to create and maintain workspaces containing 
millions of bytes of data. In fact, workspaces are lim- 
ited in size only by the amount of disc storage avail- 
able on the machine, the same limit that would apply 
to data stored explicitly as files. 

Two layers of virtual workspace implementation 
make this possible. The first layer creates, by means of 
microcode routines, a very large linearly addressed 
data space. The second layer maintains this address 
space in many smaller variable-length segments. 

To provide the large address space required to sup- 
port virtual workspaces, APL \3000 uses a set of nine 
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Fig. 1 . APL 3000 uses a virtual memory scheme to give each 
user whatever size workspace is needed, instead ol imposing 
a fixed maximum workspace size as most APL systems do. 
The virtual memory is partitioned into 2 M pages ol 2 ,v words 
each where N+M = 32 

virtual memory instructions that have been added to 
the HP 3000 Series II instruction set. These instruc- 
tions are added by installing eight read-only memory 
(ROM) integrated circuits in the CPU when APL .3000 
is installed. The virtual memory instructions take a 
small amount of main computer storage plus a large 
disc file and create what looks like one large linearly 
addressed memory. This is done using what is known 
as a least recently used (LRU) virtual memory scheme. 

The logical addresses used by APL\3000 are 32-bit 
quantities. The M most significant bits of the address 
are considered the page address and the N least sig- 
nificant bits the word-in-page address. Thus the vir- 
tual memory is partitioned into 2 M pages of 2 N 
words each (see Fig. 1). The values for N and M are 
determined by APL 3000 to provide efficient use of 
the computer hardware. N plus M must add up to 32, 
so the virtual memory can contain up to 2 3J words 
(4.294,967,296 words). This is the only theoretical 
limit to workspace size. 

The HP 3000 main computer store is set up to con- 
tain a number of 2 N -word pages from the virtual mem- 
ory along with a small status table for each main- 
store-resident page. Each status table contains the 
following information: 

■ The virtual memory address of the first word in 
the page 



■ A link that points to the next status table 

■ An indicator that tells whether data in the page 
has been modified since the page was brought into 
main storage from the disc 

• The main storage address of the words in the page. 

Fig. 2 shows how these status tables are arranged in 
main store along with the data from the pages. The 
status tables are arranged in a list with each status 
table pointing to the next status table. This list is 
always arranged so the status table for the most re- 
cently used page is the first entry in the list. 

Operation of the virtual memory instructions can 
be illustrated by describing the execution of a VIRTUAL 
LOAD instruction (see Fig. 3). This instruction re- 
quires a 32-bit virtual address as its operand and 
returns the word stored at that location in virtual 
memory. To accomplish this the first task is to deter- 
mine the page in which the word resides (the page 
address). This is done by taking the M most signifi- 
cant bits of the virtual memory address. The second 
operation is to find where the required page resides. 
This is done by first searching down the list of status 
tables to see if the page is in main storage. If the page 
is found in the list then the word requested is already 
in main storage and all that need be done is to use the 
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Fig. 2. Al a given time, the mam computer store contains a 
number ol 2 h '-word pages Irom the virtual memory along with a 
small status table lor each ol these pages The status tables 
are arranged m a list with the table lot the most recently 
accessed page al the lop ol the list. 
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Fig. 3. " the page that contains the word addressed is not in 
mam storage, the system brings in the required page trom the 
disc, swapping it tor the page whose status table is at the 
bottom oi the list, that is. the least recently used page. 

word-in-page part of the virtual address to access it. If 
the end of the status table list is reached without 
encountering the required page then a software 
routine is called from the virtual instruction mi- 
crocode. This routine decides which of the current 
main-store-resident pages can be overwritten with 
the data from the new page, stores the current page on 
the disc if it has been altered since being loaded, and 
reads in the new page. 

APL \3000 always chooses the least recently used 
page as the one that can be removed. This is the page 
whose status table is the last one in the status table 
list, since the list is maintained with the most recently 
used page first. This method is critical to the efficient 
operation of virtual memory, because it causes the 
pages that are used frequently by APLA3000 to re- 
main in main storage where they can be rapidly ac- 
cessed while the infrequently used pages migrate to 
the disc. 

Virtual Segmentation 

For this large linearly addressable virtual memory 
to be useful in creating virtual workspaces the ad- 
dress space must be broken up into several small 
blocks of memory, each of which can be indepen- 
dently expanded or contracted in size. In APL \3000 
this is accomplished by three software routines. The 



first routine allocates blocks of memory; it is given the 
required number of words and it returns the starting 
virtual address of the block allocated. The second 
routine returns previously allocated blocks of mem- 
ory to the free list where they are available for later 
reallocation. The third routine can be instructed to 
expand or contract the size of a currently allocated 
block of memory. 

The virtual storage allocation routines work with a 
data structure called the free storage list (FSL). The 
FSL contains an entry for each block of unused stor- 
age in the virtual workspace. Each entry in the FSL 
contains the following items: 

i A 32-bit virtual memory address that is the begin- 
ning of a free block of virtual memory 
■ The number of words in the free block of memory. 

When a block of storage is returned to the FSL by 
the software a description of the block is put into the 
FSL so that no two FSL entries describe adjacent areas 
of memory. In this way the free storage available in a 
workspace is represented by the minimum number of 
FSL entries. 
Conclusion 

APL is a convenient language because its work- 
space concept allows the programmer to use variables 
rather than files. APL .3000 has extended its useful- 
ness by allowing workspaces to be extremely large. 
Also, storage use and speed have been optimized by 
means of shared data areas and subscript calculus. 
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APLGOL: Structured Programming 
Facilities for APL 

by Ronald L. Johnston 



OVER A PERIOD OF YEARS the computer science 
community has developed a set of programming 
disciplines for systematic program design that have 
become widely known as structured programming. 
One very important component of this science is a set 
of interstatement control structures for clearly ex- 
pressing the flow of control. These control structures 
are embodied in such block-structured languages as 
ALGOL or PASCAL, and therefore these languages 
have been widely used in teaching computer science 
in colleges and universities. One control structure 
that has received much criticism as unstructured 
and harmful is the GOTO of FORTRAN and other 
languages. - ,7,8 The use of the GOTO, it is argued, is 
to be avoided because it can render program flow 
unintelligible, unmaintainable, and impossible to 
prove correct. 

APL is a modern language with array-oriented 
functions, but only a single branching construct is 
available: ->expression. where "expression," how- 
ever complex, evaluates to a statement number to 
which control is transferred. This construct is the 
rough equivalent of a computed GOTO which, as men- 
tioned previously, is not considered a good struc- 
tured programming tool. Many APL enthusiasts, in 
defense of the language, have argued that its rich set 
of array functions reduces the necessity of including 
explicit loop constructs in an APL program, thereby 
minimizing the importance of good control structures 
in this particular language. Nevertheless, empirical 
studies 2 of APL programs have shown that the fre- 
quency of branching per line is greater in APL than in 
FORTRAN, although there are fewer branches per 
equivalent function. Furthermore, as a consequence 
of having only one branching construct the control 
flow even within well structured APL programs can 
often be obscure. 

Many attempts have been made to improve the 
readability and understandability of the APL branch 
function. Saal and Weiss- relate that APL program- 
mers use various stylized forms of branching with 
great frequency in an attempt to imparl some regular- 
ity to the branch construct, These constructs have 
become much-used idioms of the language. Other 
APL programmers, M S dissatisfied with even these 



stylized branching constructs, have invented special 
packages of APL functions that attempt to provide 
more acceptable control structures like 1F-THEN-EI.SE. 
WHILE-DO, CASE, and REPEAT-UNTIL. However, these 
special functions have discouraged their own use be- 
cause they occupied storage in workspaces that were 
already too small, and because the function calls im- 
posed a run-time speed penalty on the user. The only 
acceptable solution lay in enhancing the language 
itself, so that APL programmers could use the grow- 
ing body of structured programming techniques 
without incurring the penalties inherent in the solu- 
tions to date. 

Solution: APLGOL 

APL \3000 includes an alternate language. 
APLGOL. which enhances standard APL in the area of 
branching. Based on the work of Kelley and Walters*, 
APLGOL is a fully-supported language that adds 
ALGOL-like control structures to APL to provide the 
needed structured programming facilities. Program- 
mers writing in APLGOL can make use of such famil- 
iar constructs as IF-THEN-ELSE, WHILE-DO, REPEAT- 
UNTIL, and CASE. Some constrained forms of struc- 
tured branching are also included; they are LEAVE, 
ITERATE, and RESTART. The resultant programs are 
much easier to read, understand, and maintain than 
the equivalent programs written in standard APL. 
These qualities are essential in production pro- 
gramming environments. 

Another language facility. ASSERT, has been incor- 
porated to encourage programmers to assert correct- 
ness properties of algorithms as they write them, 
hopefully to foster the proof-of-correctness approach 
to programming that Dijkstra has recognized as so 
important to the production of error-free pro- 
grams. B ' 910 Using ASSERT statements the pro- 
grammer states properties and conditions that must 
be true if the program being written is to work prop- 
erly. For example, suppose a function uses the vari- 
able A as a divisor and the programmer expects that 
no element of A should ever be zero. The following 
assertion might be included in the function ahead of 
the division: 

ASSERT I: A/A*0: 
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Fig. 1. An APL function ana its APLGOL counterpart. Tie two 
lunctions are nearly identical, but the APLGOL lunction makes 
use ol ALGOL-like control structures mat make it easier to 
read, understand, and maintain. 

In this fashion the programmer lets the correctness 
proof and the program grow hand in hand. Each AS- 
SERT statement contains a relational expression that is 
evaluated dynamically each time control reaches it. If 
the assertion proves false, execution is halted to per- 
mit the programmer to choose an appropriate course 
of action. Assertion statements can be conditionally 
executed, based on a level number in each assertion. 
One useful way to employ assertions is to have all 
assertions checked during initial program writing 
and debugging. Later, as the program reaches produc- 
tion status, assertion checking is turned off. If at some 
future date the program exhibits erroneous behavior, 
checking of assertions can be easily reinitiated, 
greatly facilitating debugging efforts. Using asser- 
tions in this fashion, there is no run-time penalty 
during production use of the programs; only during 
debugging stages are the assertions checked. 

A workspace may contain both APL and APLGOL 



functions, which may call each other without restric- 
tion. (However, any given function must be entirely 
APL or entirely APLGOL.) APLGOL expressions are 
exactly the same as APL expressions, following the 
same set of syntax and semantic rules. A function 
originally developed in APL can be easily modified to 
become an APLGOL function, and vice versa. The 
only differences between APL and APLGOL func- 
tions lie in the specific syntax of the function headers, 
the control structures, the use of the lamp symbol (n) 
as a comment terminator, and the fact that APLGOL, 
like ALGOL, terminates statements with a semicolon. 
Fig. 1 contrasts an APL function with its equivalent 
APLGOL function, illustrating how nearly identical 
the two functions are. 

Canonical Forms 

For run-time efficiency, it has been customary for 
APL interpreters to translate functions from character 
form into an internal form, whereupon the original 
character source is discarded. Subsequent requests 
for display of the functions are satisfied by translating 
the internal form back to a canonical character form. 
APL programmers have become accustomed to this 
canonical form of their programs being slightly dif- 
ferent from what they originally input, in that un- 
necessary blanks have been compressed out, labels 
"undented", and the formats of numeric constants 
perhaps changed. The short function shown below 
illustrates how the original and canonical forms may 
differ for APL: 

Original APL 

[0] R- PART PERCENT WHOLE 

[1] R "-1E2 x PART + WHOLE 
Canonical APL 

[0] R— PART PERCENT WHOLE 

[1] R — 1 00 x PART h- WHOLE 
In similar fashion, APLGOL translates to internal 
form and back-translates to a stylized canonical form. 
However, APLGOL canonical form may be markedly 
different from the original. APLGOL can be input 
free-form with many statements per line, but the ca- 
nonical form always has one statement per line, with 
indenting for each layer of nesting. As Fig. 2 shows, 
the canonical form of this function offers the advan- 
tage of making the control structures more obvious by 
indenting the IF-THEN-ELSE statements. 

One consequence of the APLGOL control structures 
is that the keywords of these structures (IF. THEN, etc.) 
are reserved and cannot be used as variable or func- 
tion names in APLGOL functions. This is not usually 
a severe limitation to the programmer. 

Important Design Considerations 

APLGOL is a fully-supported language, not an 
add-on to APL. The decision was made early in the 
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Fig. 2. User inputs in APLGOL are translated to an internal 
lorm and back-translate to a canonical 'orm The canonical 
form makes the control structures more obvious by indenting. 

design stages that it was to be as convenient to use as 
APL and should require no extra steps for the pro- 
grammer. It was to suffer no significant speed or space 
penalties, but should offer itself as a viable alternative 
lo programming in APL. 

One important design decision was to use the same 
dynamic incremental compiler for both APL and 
APLGOL (see article, page 17). Once a function has 
been translated to internal form (S-code), its incre- 
mental compilation and execution is handled by a 
single mechanism that is common to both languages. 
The most obvious payoff from this approach is that 
only one such system needed to be implemented, 
resulting in lower development costs than if two 
separate compilers had been written. A second, less 
obvious advantage is that Ibis guarantees that there 
are no insidious semantic differences in the way each 
language evaluates its expressions. That is. an ex- 
pression like + / gives the same result (DOMAIN 
ERROR in some systems, including ours; 0 in other 
systems) in both languages. Finally, it guarantees that 
the execution speed of both languages is the same, 
except in functions dominated by branching over- 
head, In these cases APLGOL tends to be slightly 
faster, because it generates more efficient branching 
code. APLGOL branches don't have to be range- 
checked at run time as APL branches do. since all 
APLGOL branches are generated and guaranteed in- 
range by the character-to-internal translator when the 
function is created. 

These considerations continually influenced the 
design of APL 3000, most often having the effect of 



complicating internal code assignments, data struc- 
tures, and support routines. The result, however, is a 
system that honestly supports both APL and APLGOL 
without nolicable favoritism of either. E 
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SPECIFICATIONS AND FEATURES 

APL 3000 (Language Subsystem 321 05A) 

APL 3000 Is a language subsystem lha! runs under the control ot Multi- 
programming Executive (MPE) on the HP 3000 Series II Computer 
COMPATIBILITY: APLSV compatible, including system functions and vanables, 
shared variable mechanism, Format Execute li) Scan( ), and Matrix 
Inversion and Division (E) 
FILE SYSTEM: Full access to the Multiprogramming Executive (MPE) lite system 
allows private or shared tiles via the Snared Variable mechanism, communica- 
tion with other language subsystems, access to penpheral devices (line printers, 
card readers, magnetic tapes, discs, etc.). 
APLGOL: An alternate language lhat provides modern ALGOL-like control struc- 
tures in an APL environment. IF-THEN-ELSE BEGIN-END. WHILE-DO. 
REPEAT-UNTIL, CASE, and ASSERT are among the constructs available. 
EDITOR: Full lunction and text editing facilities are provided lot by a powerful 
new editor. Includes features never beloro available to APL programmers, among 
them the ability to create and edit matrices and vectors. Provides such com- 
mands as CHANGE COPY FIND. RESEQUENCE, and UNDO, as well as 
a HELP facility for the novice or occasional user 
CONCEPTUAL DATA TYPES: Chataclet and Numeric. 
ACTUAL DATA TYPES: APL automatically chooses the apptopnate internal 
repteseniatton lot data Irom the following types. 
CHARACTER: represented by B-bit codes following the code assignments out- 
lined by i Av. Codes include lower-case ASCII alphabetics, control codes 
BIT values 0 and 1 packed 16 per machine word for data ol rank 1 (vector) or 
greater (array). 

INTEGER: integer values within the range -32758 to 32767 are stored as '6-bil 
signed integers 

REAL real values within the range -(2~ z56 . 2 ' 256 ) are stored as 64-bil 
floating point numbers 16 decimal digit accuracy 
MAXIMUM ARRAY RANK: 63 dimensions. 
MAXIMUM ARRAY SIZE: 33.767 elements. 

ARITHMETIC PROGRESSION VECTORS: Integer vectors that can be de- 
scribed by the form A -B • :C are stored as Arithmetic Progression Vectors 
(APVs). which require no data areas 

SHARED DATA AREAS: Variables of rank 1 (vector) or greater can share the same 
data areas, avoiding multiple copies of the same data. Shared dala areas are 
duplicated only if one ol the sharing variables attempts to change its data. 

WORKSPACE SIZE: Limited only by the amount ol on-line disc storage available, 
initial Size: 32.767 bytes. Automatically made larger as necessary Practical 
limit: 400,000,000 byles. 

TERMINAL SUPPORT: Accepts terminals, with or without an APL character set, 
lhat use a standard ASCII interlace ai speeds Irom 110 to 2400 baud. Pro- 
visions made lor both bit and character pairing terminals Special support 
given to Ihe HP 2641 A Display Station to take advantage ol its special leatures. 
The following other terminals have been tested: Anderson Jacobson 630, 
Computer Devices Teleterm 1030. Data Media Elite 1520. Gen-Com System 
Model 300 

ENVIRONMENT: Runs as a standard subsystem under control ot Multipro- 
gramming Executive (MPE). Allows batch APL lobs, simultaneous use of 
live other languages (BASIC, COBOL, FORTRAN. RPG, and SPL), networked 
access lo other HP 3000 s. 

SYSTEM REQUIREMENTS AND PERFORMANCE: The minimum system re- 
quired is an HP 3000 Series II with 256K bytes ol memory operating under MPE II : 
lor mullilmguai operation, at least 384K bytes ol memory is needed. Operation 
with 10 or more terminals requires lull memory (512K bytes). Maximum 
recommended number of simultaneous APL users is 16. 

INSTALLATION: APL 3000 includes hardware microcode and must be installed 
by a laclory authorized Customei Engineer Installation is included in the list 
price. 

ORDERING INFORMATION: 32105A APL 3000 Subsystem. Includes the 
dynamic compiler, hardware microcode, and Ihe APL 3000 Relerence 
Manual (32105-900021 All soltware supplied in object code lorm only. 

PRICE IN U.S.A.: S15.000. 

MANUFACTURING DIVISION: GENERAL SYSTEMS DIVISION 
5303 Stevens Creek Boulevard 
Santa Clara. California 95050 U.S.A 

SPECIFICATIONS 

HP Model 2641A APL Display Station 

General 

SCREEN SIZE: 127 mm (5 in) • 254 mm (10 In) 

SCREEN CAPACITY: 24 lines ■ 80 Columns (1.920 Character! 

CHARACTER GENERATION: 7-9 enhanced dot matnx: 9- 15 dot character 

cell: non-interlaced raster scan 
CHARACTER SIZE: 2.46 mm 1.097 in) . 3.175 mm (. 125 in) 
CHARACTER SET: 128 character APL: 64 character upper-case Roman 64 

character APL overstrike. (Note the 2641 A supports only one additional 



character sel.) 
CURSOR: Blinking underline 

DISPLAY MOOES: White on black: black on white (inverse video), blinking, half- 
bright, underline 
REFRESH RATE: 60 Hz (50 Hz optional) 
TUBE PHOSPHOR: P4 

IMPLOSION PROTECTION: Bonded implosion panel 

MEMORY: MOS ROM 24K bytes Iprogram), RAM sld. 4096 byles: 12 kilobytes 

max (16K including max. data comm buffer) 
OPTION SLOTS: 5 available 

KEYBOARD: Detachable, lull APL. ASCII code bit-pairing keyboard, user-delined 
soft keys, and 18 additional control and editing keys, len-key numenc pad: 
cursor pad; multispeed auto-repeat, N-key roll-over: 1.22m (4 loot) cable. 

CARTRIDGE TAPE (option). Two mechanisms 
REAO'WRITE SPEED 10 ips 
SEARCH'REWIND SPEED 60 ips 
RECORDING 800 bpi 

MINI CARTRIDGE 1 10 kilobyte capacity (maximum per cartndge) 

Data Communications 

DATA RATE: 110. 150. 300, 1200, 2400, 4800. 9600 baud, and external. Switch 
selectable. (110 selecis two stop bits) Operating above 4800 baud in APL 
mode may require nulls or handshake protocol to insure data integnty. 

STANDARD ASYNCHRONOUS COMMUNICATIONS INTERFACE: EIA stan- 
dard RS232C: fully compatible wilh Bell 103A modems: compatible with Bell 
2Q2GID/SrT modems Choice ol main channel or reverse channel line turnaround 
tor half duplex operation. 

OPTIONAL COMMUNICATIONS INTERFACES (see 13260A.B/C D Communi- 
cations data sheet for details): 
Current loop, split speed, custom baud rates 
Asynchronous Multipolnl Communications 
Synchronous Multipoint Communications - Bisync 

TRANSMISSION MODES: Full or hall duplex, asynchronous 

OPERATING MODES: On-line: oll-line: character, oiock 

PARITY: Switch selectable: even. odd. none 

Environmental Conditions 

TEMPERATURE, FREE SPACE AMBIENT: 

NON-OPERATING: -40 lo ♦75'C (-40 to -<-167*F) 
OPERATING: 0 to 55 C ( .32 to I 131'F) 
TEMPERATURE. FREE SPACE AMBIENT (TAPE): 
NON- OPERATING: 10 to 60 C ( - 15 lo + 140F) 
OPERATING: 5 to 40'C ( '41 to 104'F) 
HUMIOITY: 5 to 95% (non-condensing) 
ALTITUDE: 

NON-OPERATING Sea level lo 7620 metres (25.000 leet) 
OPERATING: Sea level lo 4572 melres (15.000 leet) 
VIBRATION AND SHOCK (Type lested to qualify lor normal shipping and handling 
In original shipping carton): 
VIBRATION 37 mm (0 015 In) pp. 10 lo 55 Hz. 3 axes 
SHOCK 30g. 11ms. 12 sine 

Physical Specifications 

DISPLAY MONITOR WEIGHT: 19.6 kg (43 pounds) 
KEYBOARD WEIGHT: 3.2 kg (7 lbs) 

DISPLAY MONITOR DIMENSIONS: 444 mm W * 457 mm D >: 342 mm H 

(17.5 in W » 18lnD ■: 13.5 In H). 
648 mm D (25.5 In D) including keyboard 
KEYBOARD DIMENSIONS: 444 mm W • 216 mm D • 90 mm H (17.5 in W 
* 8.5 In D - 3.5 In H) 

Power Requirements 

INPUT VOLTAGE: 115 (-10% 23%) at 60 Hz (;0.2%) 
230 (-10% -23%) al 50 Hz (=0.2%) 
POWER CONSUMPTION: 85 W to 140 W max 

Product Safety 

PRODUCT MEETS: UL requirements lor EDP equipment, ollice appliances, 
teaching equipment: CSA requirements lor EDP equipment, U.L and CSA 
labels are applied to equipment shipped lo the U.S. and Canada 

Ordering Example 

Here is an example tor ordering a 2641A Terminal with upper and lower case 
Roman character sets, line drawing character sel. cartridge tape capability 
and live extra cartridges to be operated ovet phone lines: 
2641 A APL Display Station 
-001 Adds Lower Case Roman Character Set 
•007 Adds Cartridge Tape Capability 
-013 Adds Five Mini Cartndges 

-202 Adds Line Drawing Character Set 
13232N Adds 103.202 Modem Cable— 15 ft 
PRICE IN U.S.A.: 2641A, S4100 2641A as above. S6115 
MANUFACTURING DIVISION: DATA TERMINALS DIVISION 
19400 Homestead Road 
Cupertino. California 95014 U.S A 
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A Dynamic Incremental Compiler for an 
Interpretive Language 



by Eric J. Van Dyke 



A PL OFFERS THE USER a rich selection of primi- 
tive functions and function/operator com- 
posites. Powerful data structuring, selection, and 
arithmetic computation functions are provided, and 
their definitions are extended over vectors, matrices, 
and arrays of larger dimension, as well as scalars. 

Evaluation of complex expressions built from such 
terse operations is necessarily quite involved. Code 
must be generated and executed to apply primitive 
functions to one another and to data atoms, with 
whatever type checks and representation conversions 
are required. Nested iteration loops must be created to 
extend the scalar functions over multidimensional 
array arguments, and these must include data con- 
formity and index range checks. 

All of this gathering and checking of information 
concerning data/function interaction and loop 
structure — and its high overhead expense — is, in the 
typical naive APL interpreter, simply thrown away 
after the execution of a statement. This is because the 
nature of APL is dynamic. Attributes of names may be 
arbitrarily changed by programmer or program. Size, 
shape, data type, even the simple meaning of a name 
(whether a data variable, shared variable, label, or 
function), are all subject to change (Fig. 1). Assump- 
tions cannot be bound to names al any time and be 
counted on to remain valid on any subsequent loop 
iteration or function invocation. For this reason. APL 
has traditionally been considered too unstable to 
compile. 

From this dilemma — high cost and wasted over- 
head that penalize interpretation but instability that 
prevents compilation — grew the dynamic incremen- 
tal compiler of APL \3QQ0. 

Compile Only as Required 

The APL v300Q dynamic incremental compiler is 
an interactive compiler/interpreter hybrid. It is a 
compiler that generates and saves executable object 
code from a tree representation of each new APL 
expression lor which none already exists. (In general, 
each assignment statement, branch, or function invo- 
cation is considered an expression.) It is also an in- 
terpreter that immediately evaluates every expression 
of a statement or function. Whenever possible, previ- 
ously compiled and saved code for an expression is 
re-executed. Only when absolutely necessary is new 
code generated. Thus stable expressions are com- 



piled, while those with dynamically varying attri- 
butes and those that are executed only once are. in 
essence, interpreted. The overhead of new code gen- 
eration is borne only when necessary, often only 
once. This scheme of infrequent overhead provides 
justification for costly optimizations, including the 
dragalong and beating discussed below, that lead to 
more efficient code. 

A balance between compiling and interpretation is 
accomplished through the generation and execution 
of signature code, binding instructions that are emit- 
ted before the code for an expression. Their purpose is 
to specify and check the attributes that are bound into 
the following code, that is. constraints that may not 
change if the compiled code is to be re-executed. 
Signature instructions are generated that test index 
origin (0 or 1). meaning of names (whether data vari- 
able, shared variable, or otherwise), type and dimen- 
sions of expressions (representation, size, and shape), 
access information for data (origin and steps on each 
dimension), and run-time index bounds checks. 

These signature instructions are bypassed on the 
first execution after compilation, when all assump- 
tions are guaranteed satisfied. On subsequent execu- 
tions, the signature code is used to test the validity of 
the code that follows. If these assumptions are found 
to be invalid, the code "breaks". Execution is re- 
turned to the compiler and code with a new set of 
assumptions is generated (Fig. 2). On recompilation. 
an expression is assumed unstable and a not-so- 



ANS«— A + B 



Integer Scalar Variable 
Dyadic Primitive Function 
Integer Scalar Variable 



4 



[A Numeric Valuel 



ANS > 



A + B 



Real Vector Variable 
Dyadic Primitive Function 
Character Matrix Variable 



Monadic User-Defined Function 
Monadic Primitive Function 



[A Domain Error] 



ANS— A + B 



111 

[A 



Nlladic User-Defined Function 



i Numeric Value) 



Fig. 1. APL is dynamic. Attributes of names may be arbitrarily 
changed by the programmer or by a program. For this reason, 
APL has been considered impossible to compile. 
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Fig. 2. In APL '■•3000. expressions are compiled when lirsl 
encountered Along with the compiled code signature code is 
generated, specifying constraints thai must be met il the code 
is to be re-executed. This signature code is tested on sub- 
sequent invocations ol the expression, and if the constraints 
are not met. recompilation is required. 

specific but somewhat slower and less dense form of 
code is generated. Further changes may not force a 
recompilation. 

Wait as Long as Possible; Do as Little as Necessary 

The secret to compiling efficient code is in gather- 
ing, retaining, and exploiting as much information 
about the entire expression as possible before generat- 
ing code. The more context that can be recognized, 
the more specific "smarts" can be tailored into the 
code. For this reason, the APL\3000 compiler oper- 
ates in two distinct functional passes: context gather- 
ing and code generation. 

The context gathering, or foliation, phase of compi- 
lation is a complete bottom-up traversal of the expres- 
sion tree. Fig. 3 shows an example of such a tree. 
Description information is associated with each of the 
constant and variable data nodes — the leaves of the 
tree. These descriptions are then "floated" up to in- 
teract with the parent node. Descriptions are revised 
and attached to the corresponding node as necessary 
to suit the result. This process continues as descrip- 
tions are gathered and carried up through each func- 
tion or operator node toward the root. Attached to the 
final assignment or branch node will be a context 
description for the entire expression. Fig. 4 shows the 
loliated tree for the expression of Fig. 3. 

The information created by this foliation process 
consists of a set of auxiliary description nodes at- 
tached to each node in the expression tree. Each of 
these description groups contains the attributes of the 
result of the expression to which it is attached, as 
modified by that function and those below. First in 
the set of descriptor nodes is a single RKR node, which 




Fig. 3. The tree representation of an expression The 
APL \30O0 compiler traverses this tree twice, once for context 
gathering and once for code generation. 

describes the general structure of the current expres- 
sion: rank (number of dimensions — for scalar, 0), 
REPRESENTATION (internal data type), and RHOs (size of 
each dimension — for scalar, there is none). Linked to 
the RRR node is a chain of DELOFF nodes, or data access 
descriptions, at least one for each non-scalar data item 
in the expression. A DELOFF node indicates the order 
in which an item is accessed and stored — row major, 
for example — by means of an offset (origin), and a 
DEL (step) for each coordinate. Notice that these de- 
scriptions are independent of the data: storage need 
not be accessed during this foliation process. 

Frequently, data storage is shared. In such cases, 
multiple descriptors are created, perhaps with differ- 
ing access schemes. Each addresses the same shared 
area. A common form of vector data created by the 
INDEX GENERATOR function is the arithmetic progres- 
sion vector (APV). This vector may be completely rep- 
resented by its descriptor: no data area is necessary at 
all. For example, 2+3* 14 requires only tbe descriptor: 

RHO: 4 OFFSET: 5 DEL: 3 

to represent the values 5 8 11 14. 



Dragalong and Beating 

It is the gathering and manipulation of these data- 
independent descriptors, following the dragalong 
and beating strategies developed by Abrams, 1 that 
makes possible the extensive optimizations incorpo- 
rated in APL\3000. 

Dragalong. the strategy of deferring actual evalua- 
tion as far as possible up the expression tree by gather- 
ing descriptions, avoids the naive interpreter's usual 
one-function-at-a-time "pinhole" evaluation. In- 
stead, the code for a collection of parallel functions, 
including their associated loops, can be generated 
and executed simultaneously. Fig. 5 compares naive 
with dragged code. 

Beating, the application of Abrams" subscript cal- 
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Fig. 4. Foliated expression tree results trom the context gathering phase ot compilation Auxiliary 
description nodes contain the attributes ot the sub-expression to which they are attached 



cuius to a deferred expression when evaluation is 
finally required, produces the desired results for cer- 
tain APL functions by description manipulation 
alone. In such cases, the original data is shared with 
the beaten result, making it unnecessary to copy the 
data in a different form. Thus data is touched only 
when and only as much as necessary. (Data sharing is 
described in more detail in the article beginning on 
page 6.) SUBSCRIPTION, RESHAPE, RAVEL, TAKE, DROP. 
REVERSAL, and monadic and dyadic TRANSPOSE are the 
functions to which beating optimizations may be 
applied (see Fig. 6). 

The dragalong and beating strategies can signifi- 
cantly reduce the amount of data access and storage. 



computation and looping overhead, and often tempo- 
rary storage required in the evaluation of an expression. 

An independent context gathering pass during 
compilation provides an opportunity for a number of 
specific optimizations in addition to dragalong and 
beating. For example, a pair of adjacent monadic RHO 
nodes can be recognized as a new internal RANK func- 
tion. The result is merely the rank of the argument as 
indicated by its description, eliminating the need for 
an intermediate rho vector (see Fig. 7). Similarly, 
successive CATENATE nodes can often be incorporated 
into a new multi-argument polycat function, elimi- 
nating the superfluous data moves and intermediate 
storage that would normally be required (Fig. 8). 



Naive 

INITIALIZE INDEX I AND LIMIT 
WHILE INDEX • t LIMIT DO 
BEGIN 

TEMPORARY [INDEX I \> B\lNDEX I \ -C[lNDEX I | 

INCREMENT INDEX I 

END 
INITIALIZE INDEX 2 
WHILE INDEX! * LIMIT DO 

BEGIN 

ANS \INDEX 2 | A [INDEX 2 | • TtMPORARV\lNDEX 2 

INCREMENT INDEX 2 

END 



Dragged 

INITIALIZE INDEX AND LIMIT 
WHILE INDEX * LIMIT DO 
BEGIN 

ANS | INDEX | - A [ INDEX | ♦ S | INDEX |XC| INDEX [ 

INCREMENT INDEX 

END 



Fig. 5. Evaluation ot an expres- 
sion is deterred as long as pos- 
sible This strategy, called drag- 
along, makes it possible to gener- 
ate and execute the code tor a 
number of parallel functions simul- 
taneously, avoiding the naive in- 
terpreter's one-lunclion-at-a-time 
evaluation Shown here is a com- 
parison ot naive with dragged 
code lor ans-a+bxc. a, b, and C 
are conlormable vectors. 
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Fig. 6. When evaluation is finally required, beating, or the 
application ol the subscript calculus to a deferred expression, 
may produce results by description manipulation alone. Here 
take (T) and reversal (<}) are applied to descriptions for a 
simple expression. The dragalong (see Fig. 51 and beating 
strategies can significantly reduce the computation and stor- 
age required in the evaluation ol an expression. 



APL \3000's target machine is a software/firmware 
emulator implemented on the HP/3000. The instruc- 
tion set, in addition to loads, stores, and loop and 
index controlling instructions, includes a set of high- 
level opcodes that match the APL primitive scalar 
functions. Code generation from an expression fol- 
lows a recursive descent of the tree: an instruction to 
set up a storage area for the result (typically a tempor- 
ary] is emitted, followed by a reverse Polish sequence 
of data loads and operations, and finally a store into 
the result, all nested within the necessary loops. 

Any instruction that has the potential to fail carries 
within it a syllable number that provides the machine 
with a pointer to the original source in case of an 
error, allowing for recompilation on binding errors or 
message generation on user errors. 

The descriptions at the root node completely de- 
scribe all index variables and iteration loops to be 
generated. Each DELOFF node, with optimizations 
beaten in. describes the initialization (OFFSET) and 
stepping (DEI.) of an index register. The loops, one for 
each dimension of the result, in general, are derived 
from the RRR in conjunction with a selected DELOFF. 
Loops are all of a basic structure: 
INITIALIZE ALL INDEX REGISTERS 
INITIALIZE LIMIT REGISTER 
WHILE CHOSEN INDEX * LIMIT DO 
BEGIN 

INITIALIZE LIMIT REGISTER 
WHILE CHOSEN INDEX * LIMIT DO 
BEGIN 

(Indexed Expression Code) 

INCREMENT ALL INDEX REGISTERS 
END 

INCREMENT ALL INDEX REGISTERS 
END 

Equality, unlike > and <. is a consistent termina- 
tion condition for loops that may run in any direction. 
For each loop, a DELOFF node is selected to serve as the 
loop-controlling induction variable. Because of their 
special uses, certain indexes are not eligible (those for 



Code Generation 

When the compiler is finally forced to materialize 
an expression — either the root has been reached, or 
the compiler can drag no farther for one reason or 
another — code is emitted. This code generation pass 
is a second independent walk of the foliated tree with 
dragged and beaten descriptions attached, this time 
from the top down, generating and saving executable 
code for the expression. By exploiting the context 
descriptions that have been gathered up the tree from 
each node, specifically tailored code can be gener- 
ated. Because APL in general deals with arrays, this 
process also usually involves the construction of 
loops. 




Fig. 7. The context gathering pass provides an opportunity 
lor specific optimizations, such as recognizing a pair of adja- 
cent monadic rho nodes as the new internal rank function 
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A Controller for the Dynamic 
Compiler 

by Kenneth A. Van Bree 



Tne controller lor the dynamic compile' performs an of ihe 
tasks an nterpreter for APL must perform, such as Handling user 
mpul and editing, seauencmg between lines of a function 
calling and returning from user-defmed functions, and handling 
errors In aodition. the controller handles the generation and 
re-execution of compiled code for APL statements 

One of the guiding assumptions m the design of the controller 
was that code for a particular statement could be compiled once 
and would remain valid for many re-executions of that 
statement This assumption was based on the observation that 
most APL programmers do not take full advantage of the 
dynamic capabilities of APL Changes In the value or size 
(number of elementsl of a variable are frequent, but changes hi 
the shape or representation of a variable are rare For this 
reason, the controller has been designed to re-execute com- 
piled code as quickly as possible, while still maintaining the 
tlexibihty needed to perform all Ihe other duties related to 
controlling an interactive language such as APL 

The controller consists of five interacting modules as shown in 
the diagram Each module performs a subset of the duties 
related to controlling the compiler, and any module can call on 
any other module to perform a task that it cannot do itself The 
normal flow of control for an APL expression input by the user (in 
calculator mode) 'S as follows 

Text tor the expression is input by the user through the user 
mput and editing module This module is m charge of all 
interactions with the user, and before control leaves this 
module, all text that the user enters is converted into an internal 
form called S-code S-code is a compact form ol the text, with 
each identifier replaced by an internal short name lor easy 
reference The actual text that the user enters is not saved, but is 
regenerated from S-code il needed 

Once S-code has been created, control is passed to the line 
statement sequencing module, which handles the dynamic How 
of control between lines and statements in APL As each 
statement is executed, this module checks to see whether it has 
been executed before If a statement has never been executed 
before a syntax analysis is done on the S-code for that 
statement The result of the syntax analysis is one 01 more syntax 
trees called D-trees Each D-tree represents the largest part ol 
an APL statement thai can be guaranteed to have no side 



effects For example, m the statement A— B*C it C is a 
user-defmed function, then tne statement win oe broken up into 
two trees The first tree will materialize the function C into a 
temporary variable, and the second tree will add the results of C 
to B and assign the sum to A 

As soon as D-trees have been created for a statement, control 
is passed to the executable code creation sequencing module 
Within this module, eacn D-tree for a statement is examined in 
sequence, and if it does not represent a function call, it is 
passed to the dynamic compiler The compiler turns each 
D-tree into a block of executable code called E-code The 
compiler calls the execution machine directly to execute the 
E-code that it has created 

Once a valid block of E-code has been created from a D-tree 
the executable code creation sequencing module is in charge 
of storing that E-code block for later reference As each D-tree is 
compiled, the E-code block created is used to replace the 
D-tree When all trees for a statement are compiled Ihere will 
exist a series of E-code blocks that represent the statement On 
subsequent executions of a statement, the E-code blocks are 
retrieved and given directly to the execution machine. If the 
code contains a non-fatal error such as a change in representa- 
tion or rank of a variable, the execution machine returns a 
non-fatal error indication to the executable code creation; 
sequencing module which calls the non-fatal error handier to 
correct the problem The non-fatal error handler recreates a 
D-tree tor the part of the statement affected by the non-tatai 
error New E-code is then compiled with the non-latal error 
corrected, and the new E-code biock is saved in place of the 
one in which the error was found 

If the executable code creation/sequencing module detects 
that a particular D-tree represents a funclion call, then control is 
passed to the user-defined function call and return module It 
the line statement sequencing module detects a function return, 
it can also pass control directly to the user-defmed function call 
and return module 

II any of the other modules detects a tatai error, such as an 
undefined variable or a syntax error, control is passed directly to 
the fatal error handler This module suspends execution, prints 
an error message for the user, and then returns control to the 
user input and editing module to wait for input from the user 
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Fig. 8. Another optimization that 
can be effected during context 
gathering is combining succes- 
sive catenate nodes into a new in- 
ternal poly cat function. 



single-element arrays that will never be incremented, 
for example, or the left indexes of COMPRESS and EX- 
PAND, which are incremented asynchronously). 

A limit for each loop, calculated as OFFSET * RMO x 
DEI. (on the appropriate coordinate, from the chosen 
induction variable) plus the current induction vari- 
able, is also created in a register. Except for the outer- 
most (or only) loop limit, which may be constant, the 
limit value must be calculated at execution time. In- 
itialization values and increments for all indexes cor- 
respond to the OFFSETS and dels of their associated 
DEI.OIT descriptors. Fig. 9 shows the code generated 
for a vector expression. 

A number of optimizations are performed prior to 
the generation of loops. Except for actual display, an 
expression represented as an arithmetic progression 
vector (APV) requires no evaluation loop at all; its 
description completely specifies the result. Redun- 
dant index variables, which would run in parallel, are 
shared by collecting those DELOFF nodes having iden- 
tical attributes into a single register. If. according to 
the descriptors, a loop is unnecessary, as is often the 
case with row-major compact storage, it is collapsed, 
subsumed by the next outer loop. 

In addition, certain improvements in the code can 
be made. Unlike larger data structures, in which data 
can be partially destroyed if an error is encountered, 
scalar and single-element expressions can be gener- 
ated without assignment to an intermediate tempor- 
ary variable, eliminating the setup, some use of stor- 
age area, and the resulting data swap. Occasionally, 
when the result produced from such a unit expression 
involves itself, a new data area need not be set up at 
all. Instead, the old name is retained for the result of 
the expression. Subexpressions yielding a scalar or 
single-element array within the scope of a loop can 
frequently be materialized, or assigned into a tempor- 
ary cell, outside the loop, eliminating their repeated 
evaluation. The more complex argument to an OUTER 
PRODUCT operator can similarly be constrained to an 
outer code loop, affording it less frequent evaluation. 

Hard and Soft Code 

The code generated by APL \3000 is of two types. 



Initially, hard or tight code is produced. In this style 
of code, the Rlios. offsets, and DELs, as well as rank 
and REPRESENTATION are bound into the instructions 
as constants. If this specific form of code has broken 
and a recompilation is required, more general soft or 
loose code is generated, in which only the RANK and 
REPRESENTATION are bound. RHOs, DELS, and OFFSETS 
may be calculated in registers at run time. Thus the 
dimensional attributes of an array may dynamically 
change without invalidating the code again. 



SET UP STORAGE AREA FOR RESULT TEMP 
INITIALIZE STORING INDEX TO 0 

[OFFSET FOR ANS AND TEMP I 
INITIALIZE VECTOR ACCESSING INDEX TO 2 

IOFFSET FOR VECTOR BEATEN BY ) ) 
INITIALIZE APV ACCESSING INDEX TO 1 

IOFFSET FOR 13) 
INITIALIZE LIMIT TO 3 

(flHO » DEL * OFFSET ■ STORING INDEX) 

WHILE STORING INDEX 'LIMIT DO 
BEGIN 

LOAD APV ACCESSING INDEX 

INTEGER LOAD OF VECTOR \ VECTOR ACCESSING INDEX , 

INTEGER MULTIPLY 

CONVERT TO REAL 

REAL LOAD OF CONSTANT 1 1 

REAL ADD 

REAL STORE INTO TEMP [STORING INDEX\ 
INCREMENT STORING INDEX BY 1 

(DEL FOR ANS AND TEMP) 
INCREMENT VECTOR ACCESSING INDEX BY 1 

(DEL FOR VECTOR BEATEN BY }) 
INCREMENT APV ACCESSING INDEX Bv 1 

(DEL FOR ;3J 

END 

SWAP TEMP INTO ANS 



Fig. 9. When the compiler can drag no farther it emits code 
The code generation phase is a second traversal of the /now 
foliated) expression tree. Because APL m general deals with 
arrays, code generation usually involves the construction ol 
loops Shown here is the code generated for the expression 
ans-i i - ( \vectoR)' i3. vectop is an integer vector of length 3. 
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Hard 


Soft 


CpT i ip CTf^BAflF JSC -*• PJ~1P PCCf it T rata 


CpT i ip ctad; 1 /? 1 c 'DC : CAE; sec, n I rrnc 




iJNiiiMLiic afOBWu >NUEX i U u 


INIIIAL'tb VECTOR ACCESSING INDEX _ i 


INITIALIZE VECTOR ACCESSING INDEX TO 


INlTIAL'ifc UwT TQ J 




WHILE STORING INDEX ~ lWFT DO 


INITIALIZE VECTOR ACCESSING INCREMENT TO 


BEGIN 


del *-hqm vector 


LOAD 1 


IWIIMUZt LIMIT >\J HMO rffUM VECTOR 


LU«U rcL> ' Uri | ret >uVf iD'rVlJ INUca 




AUU 






i nan 1 


llNUntlVtrJ 1 blUHING INDEX D" 1 


LU"U VcC fun I VEL> IUR ACCESSING INDEX 1 


INLntMhN 1 VECTOR ACCESSING INDEX tir j 


a p,r\ 


END 


STORE INTO reMPlsron/WG INDEX | 


ClAIAD Tphtp INTO J AS? 


IINUMCIWCN 1 blUHINlj INUtA a J 1 




INCREMENT VECron ACCESSING INDEX BY 




VECTOR ACCESSING INCREMENT 




END 




SWAP TEMP INTO ANS 



Fig. 10. Code generated is of two 
types Initially, hard code is pro- 
duced. II this code later breaks, 
more general soft code is gener- 
ated Shown here is hard versus 
soft code lor the expression 
ans-i,vector) • 7. vector is an in- 
teger vector ol length 3 



For this more flexible form of instruction a price is 
paid in terms of speed and code bulk, but this over- 
head cost rarely approaches that of an entire recompi- 
lation every time a rho, offset, or DEL changes. 
Notice that RANK and REPRESENTATION must always be 
bound hard. RANK, which specifies the maximum 
number of loops to be generated, must have a constant 
value at compile time. REPRESENTATION must be 
known to determine the data type of the instructions 
issued. A change in either of these attributes always 
forces a new compilation. 

Fig. 10 compares hard and soft code emitted for a 
vector expression. 
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Extended Control Functions for 
Interactive Debugging 

by Kenneth A. Van Bree 

Several system lunctions facilitate debugging and program 
development in APL. Using the function Qss (set stop) it is 
possible to stop on any or each line of a function or on return 
from the function The Ds" (set trace) function allows the last 
result calculated on a line to be displayed along with the function 
name and line number. This is helpful tor observing program 
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flow. The !:sm (set monitor) lunction allows the user to monitor 
the number of times that a lunction and/or line has been exe- 
cuted, along with the amount of CPU time spent in each line, and 
the total CPU time spent in the function These functions can be 

Icoriiinued on uage Z4| 
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used lo determine where the majority o( the CPU time is being 
spent on a particular problem and which lines of a program have 
never been executed All of the monitoring facilities can be 
turned on or oil and queried under program control 

One reason that program deveiopmenl is so easy in APL is 
that the entire power ot APL is available to the user during 
program debugging When the APL system detects an error in a 
user program (for example, an attempt to read a variable that 
hasn't been given a value), the program is halted and an error 
message is written on the user terminal The error message tells 
the user the type of error (a value error in this example) along 
with a pointer to where the error was detected The APL system 
then returns control to the terminal so the user can try to correct 
the error At this point the state indicator (SI) may be displayed 
The state indicator is a pushdown list (i.e., stack) of all the 
user-defined functions that have been called but have noi yet 
completed execution The stale indicator displays not only the 
names of the functions that have been called, but also the line 
number on which execution was suspended. In addition, a list of 
all the local variables can be oblained for each function that has 
been called but not completed. The function in which the error 
was found is the topmost entry on the SI and is called a sus- 
pended function Other functions on the SI are called pendanl 
functions. 

While computation is suspended, the user has the full power 
of APL available to him for debugging The suspended function 
(or any other function that is not pendant) may be edited, and 
any variable that is available within the suspended function may 
be interrogated or redefined. A new computation may be started 
by calling another function, or in most cases Ihe suspended 
computation may be resumed from the line at which it was 
suspended or any other line If for some reason Ihe user does 
not wish to fix the error, the SI can be cleared, or the entire 
workspace including the SI can be saved for later reference 

The flexibility and power available to the user during debug- 
ging make it possible lo detect ana correct multiple errors 
during the course of the computation. This means that programs 
often run to completion Ihe first time they are called, because 
most errors can be fixed as they are detected A recent study of 
APL in Europe' showed that the conciseness of APL coupled 
with its ease of debugging produced a 3:1 improvement in 
programmer productivity over such languages as PL/I and 
COBOL 



In this environment the value of variable v is whatever has been 
assigned withm function s The value of v within function f has 
been shadowed (by the local variable v within g) and is not 
accessible withm the current function. All names accessible 
from function g make up Ihe environment of g, and the local 
variable v of function F is not in the environment of g Further- 
more, it is not possible to resume execution of function r without 
first completing lunction &, since the SI operates strictly on a 
last-m-firsi-out basis 

Through the use of the extended control functions of 
APL \3000 it is possible to access variables and resume execu- 
tion in environments other than the current environment The 
concept of multiple environments is not new.' but it has never 
been implemented In APL before. APL \3000 allows up to 16 
environments to be available at one time Each environment has 
its own state indicator, and control can be passed from one 
environment to another through Ihe use of Ihe extended execute 
(i) function Allhough Ihe normal SI in APL obeys a strict stack 
discipline, the environments of APL \3000 may create one or 
more computation trees. This allows the creation of environ- 
ments that share a portion of their SI When this happens, it is no 
longer possible to maintain a stack discipline lor the SI. and a set 
of pointers musi be maintained that links each function call to its 
calling function. The extended control functions maintain a 
stack discipline for the SI unless the user explicitly calls for a 
tree-like control structure The overhead paid for the extended 
control capability is minimal unless it is invoked by the user In 
Ihe above example, the environment withm lunction f can be 
captured by using the system function LjcsE (capture stack 
environment). 

EjCSE 2 n Capture second lunction name on SI 

» The environmenl number is 1 
)SIV 1 fl Display the SI tor environment 1 
F[2j V 

Environment 1 now shares a part of its SI (namely the function 
f and its local variable v) with the current environment displayed 
earlier Any arbitrary expression can be evaluated in the en- 
vironment of lunction f through the use ol the extended 
execute function For example. Ihe variable v within function f 
may be assigned the value 3 as follows 

1tV-3' 



Extended Control Functions 

The state of an APL computation can be displayea at any lime 
by interrupting the computation (by sending the attention 
character) and displaying the state indicator through the use of 
the commands isi or isiv. The slate indicator shows all of the 
functions that have been called but have not yet completed 
execution, along with the variables that are local to those func- 
tions. The current environment consists of the variables that can 
be accessed within the topmost function on the stack, along with 
the chain of control represented by the function calls that ap- 
pear on the SI Normally, withm APL, any computation must be 
done in the current environment For example, if the function f 
(which has local variable v) calls function g (which also has iocai 
variable v), and computation is suspended within g. the SI might 
appear as follows 

)Siv 
G[3]. V 
F[2] V 



Evaluating an expression in environment 1 (or any other envi- 
ronment) is equivalent to evaluating the expression m calculator 
mode with execution suspended in lhat environmenl. Execution 
can be resumed within function - by evaluating an expression 
that results In a branch. For example 

14,'-*g l 

The extended control functions in APL ' 3000 can be used for 
purposes other than debugging Since environments can be 
captured (using | ess) and released (using I rse) under program 
control, it is possible to implement such advanced pro- 
gramming concepts as backtracking, co-routines, and so on, 
which have been difficult or impossible to implement m APL 
before 
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CRT Terminal Provides both APL and 
ASCII Operation 

by Warren W. Leong 



MODEL 2641A APL DISPLAY STATION (Fig. 1) 
is a special CRT terminal designed to serve as 
the principal user interface for APL \3000. APL opera- 
tion plus extensive data communications capabilities 
allow the terminal to be used with APL interpreters/ 
compilers that exist on a variety of computer systems, 
especially the HP 3000. ASCII operation is provided 
to retain compatibility with HP 2640-Series CRT 
Terminals. 

The 2641A provides a superset of the functions 
available with the 2645A Display Station. These in- 
clude dual cartridge tape units, extended editing fea- 
tures, extended data communications, modular 
firmware implementation, and eight user-defined 
soft keys. A new, faster microprocessor provides the 
control for the standard as well as the extended fea- 
tures. 



APL Features 

Major features of the 2641A APL Display Station 
are: display of the APL character set. display of the 
APL overstrike character set*, display of APL under- 
lined characters, and non-destructive spaceover. 
These features are accessible during the terminal's 
APL mode. 

The high-resolution display of 2640 Series Ter- 
minals 1,2 provides a clear and easily readable ren- 
dition of the standard APL characters as well as the 
more intricate overstrike characters (Fig. 2). There are 
two separate APL character sets: a 128-character APL 
graphics set and a 64-character APL overstrike 



'Many APL primitive [unctions are called by striking one APL symbol, then backspacing and overstrik- 
ing ine tirst symbol with a second symbol The combination lorms a new APL symbol. The APL 
overstrike charade' set makes It possible tor the 2641A to display such combinations ot basic APL 
symbols 




1 I I 




Fig. 1. Model 2641 A APL Display 
Station is designed to serve as the 
principal user interlace lor 
APL\3000 and other APL sys- 
tems. It has both APL and ASCII 
modes of operation. 



25 



© Copr. 1949-1998 Hewlett-Packard Co. 



JEDIT TRAPEZOIDAL 
APLGOL FUNCTION 
>LI8T ALL 



PROCEDURE R»x TRAPEZOIDAL TI.DT.I .U.AT.DIO; 
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R-NrOIO-ll 
l»2| 

WHILE mi-l.l DO 
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l 

Fig. 2. Standard 2641 A character sets are the 128-character 
APL set, a 64-character APL overstrike set. and a 64-character 
upper-case Roman set. An optional fourth character set may 
be a mathematical symbol set, a line drawing set, a large 
character set, or a user-designed set. 

graphics set (Fig. 3). Each set is programmed into 
bipolar ROMs. The APL graphics set follows com- 
monly accepted industry standard code assignments. 
The APL overstrike graphics set is used internally by 
the terminal to display the overstrike characters and 
its code assignment is dependent on terminal re- 
quirements. As each valid overstrike keystroke se- 
quence is completed the proper overstrike character 
is displayed on the screen. However, the actual over- 
strike character sequence is transmitted to the com- 
puter when in character mode or is stored in the 
display memory for later transmission when in block 
mode. 

The 2640 Series Terminals can support up to four 
independent character sets. Since the 2641A APL 
Terminal includes as standard the APL set, the APL 
overstrike set, and the ASCII set, it has room for one 
additional character set. Currently this additional set 
can be a mathematical symbol set, a line drawing set. 



a large character set, or a set of the customer's own 
design. 

The keycaps have APL legends on their top faces 
and ASCII legends, when they differ, on the front 
faces (Fig. 4). This allows unambiguous operation 
whether operating in APL or ASCII mode. The 
keyboard code assignment is bit pairing* .rather than 
typewriter pairing*, to retain compatibility with the 
2640B and 2645A Terminals. The shift 0 (zero) posi- 
tion is re-assigned to mean A in APL and in ASCII; 

this provides full APL compatibility for users when 
switching between bit and typewriter pairing layouts. 

Firmware 

The controlling feature of the 2641 A APL Display 
Station is the firmware, or microprograms stored in 
ROM. All of the characteristics of the terminal are 
defined by microprogramming the internal micro- 
processor. These characteristics include switch selec- 
tion or computer selection via escape sequence of the 
two operating modes. APL or ASCII, overstrik.es that 
are recognized by the terminal, block transfers of APL 
program and data statements, and editing features 
during APL mode. 

The first consideration was how to integrate the 
APL operational requirements into the base product, 
the 2645A. Since many of the features of APL were 
distinctly different from normal operation, it made 
sense to define an APL mode for APL operations. In 
APL mode the APL character set is normally dis- 
played instead of the ASCII character set. Any attempt 
to overstrike an APL character results in the display of 
a character from the overstrike set. Underlining of 
APL characters is done by means of shift F. Block 
transfers (via the ENTER key) take into account the 
overstrike character set and decompose these into 
APL characters separated by a backspace control 
code. 

APL systems recognize several overstrikes. With 

»BK pairing: tint! codas differ Irom unsnrti codes by one bit 
Typewriler pairing: codes follow an industry standard for certain typewriter terminals. 



Fig. 3. Standard 2641 A cnarac- 
ter sets 
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line overstrikes are not a part of the character ROMs. 
Instead, the underline feature of the terminal's dis- 
play enhancement section is used to simulate the 
underline overstrike. 

The underlining process begins when an APL 
character is displayed and the cursor is repositioned 
to the character. When the underline character (shift 
F) is typed, the firmware provides the proper en- 
hancements to underline the character. 



Fig. 4. 2641 A keys have APL legends on top and ASCII 
legends, when they differ, on the front faces. 



the 2641 A. these overstrikes can be done at any time 
or in any order. Overstriking poses several complica- 
tions for a raster-scan CRT terminal that dynamically 
allocates its memory and uses separate graphics sets 
for the normal and overstrike characters. An APL user 
may type several characters, then backspace to the 
beginning of the line and overstrike the required 
characters, or the user may complete each overstrike 
before proceeding to the next character. Backspacing, 
using the backspace key. does not delete characters 
previously entered and forward spacing using the 
space bar does not erase characters that are being 
spaced over. 

The basic algorithm for overstrikes directs the ter- 
minal to monitor each byte that it writes to the dis- 
play. In APL mode, the terminal checks the current 
and new characters being typed in the same display 
position and determines whether the new character 
just overwrites the old (only when the old character is 
a blank), whether the old character is replaced by a 
new character from the overstrike set, or whether the 
old character remains unchanged (the new character 
is a blank). Overstrikes are allowed only in APL 
character fields. If the cursor is in a non-APL field, 
such as Roman, then the terminal performs ASCII 
operations rather than APL operations, although the 
operating mode is APL. 

When the old and new characters form a valid over- 
strike such as and ., then the composite ! is dis- 
played. If an invalid pair is overstruck. then an OUT 
character is displayed, providing a clear indication 
that an error has been made. 

The underline overstrike (shift F) for APL is nor- 
mally restricted by APL systems to the alphabetic 
characters and a few of the special characters. The 
2641A can underline any APL character. The under- 



Data Transfer 

All display information, overstrikes, and under- 
lines can be stored on the cartridge tape units, printed 
on a printer, or block transmitted to a computer sys- 
tem. 

Block transfers during APL mode, from the display 
or the tape units, take into account the overstrike set 
and underline enhancements. In the case of over- 
strikes, the code from the overstrike ROM is used as 
an index into a look-up table for the two components 
of the overstrike. These two components are then 
transmitted with a backspace separating them. The 
underlined characters are transmitted with the proper 
codes: the character, then backspace, then underline. 
The OUT character is treated as a special case and 
causes five characters to be output: 0 backspace U 
backspace T. 

Two types of printers are available for APL: bit 
pairing or typewriter pairing. Distinguishing the two 
are the code assignments of 19 of the characters. The 
2641A allows the user to select either translation 
when directing APL data to a printer. 

User-Defined Soft Keys 

The 2641 A has eight special-function user-defin- 
able soft keys, fi through fa. These keys hold up to 
80 ASCII characters that are specified by the user. 
This specification may be done interactively, with the 
old contents displayed while updates are done. The 
specification may also be done by escape sequence 
from a computer system or from the optional car- 
tridge tape units. 

After logging onto an HP/3000 Computer System 
having an APL x 3000 subsystem, the user specifies 
the terminal type to be a 2641A by means of the 
)TER.M HP command, and the system downloads the 
soft keys with the following commands: 



Command: 
Key: 

Command: 
Key: 



(RESUME LSI 
f! f2 



|FNS 
13 



IVARS 
f4 



ATTN ]EDIT |LOAD (SAVE 
f5 f6 f7 f8 



Now the user can invoke frequently typed system 
calls with a single keystroke. For instance, to edit a 
function named apli, the user can press ft> to call the 
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system editor, then type APLi, followed by RETURN, 
and be ready to edit. The user may also redefine these 
soft keys very simply. 

Key fs contains the ATTN command, which is useful 
during line editing. Suppose the user has typed a line 
of data but notices a mistake. To correct the error, 
the user first backspaces the cursor to the incorrect 
character: 

ABCFE 

Using the 2641 A and AP1A3000, the user then hits 
ATTN, which causes the APL terminal driver to send 
an escape sequence to clear the rest of the line: 
ABC _ 

The user continues typing from this point to complete 
the data statement: 

ABCDE _ 

The traditional method of editing is to position the 
cursor under the incorrect character, then send a line- 
feed to the computer and type the correct characters, 
producing a display like: 
ABCFE 
DE 

Note that the display can be confusing to read if 
several corrections have to be made in this manner. 
However, both methods of correction are allowed by 
the subsystem and the 2641A. 

Extended Features 

Editing features have been expanded to include 
character wraparound when the terminal is doing 
character delete or insert operations. Left and right 
margins may also be set. Extended I/O operations 
with the cartridge tape option include write, back- 
space, read, data comparisons, and data logging. 

The data communications facility allows data rates 
up to 9600 baud, and multipoint capabilities that 
allow up to 32 terminals to share a single communi- 



cations line. Self-test has been expanded to allow 
testing of the optional cartridge tapes and associated 
electronics as well as the multipoint communica- 
tions option, cabling, and terminating instrumenta- 
tion. Multipoint communications can even be tested 
up to the remote modem from the terminal keyboard. 
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